Skip to content

[xDS] A97 - JWT token file call creds #12242

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Zgoda91
Copy link

@Zgoda91 Zgoda91 commented Jul 23, 2025

implementing gRFC A97 grpc/proposal#492

@Zgoda91 Zgoda91 force-pushed the A97_jwt_token_call_creds branch 3 times, most recently from a4317bd to a8f76b0 Compare July 24, 2025 14:57
@Zgoda91 Zgoda91 force-pushed the A97_jwt_token_call_creds branch from a8f76b0 to c781460 Compare July 28, 2025 06:26
@Zgoda91 Zgoda91 marked this pull request as ready for review July 28, 2025 06:27
@Zgoda91
Copy link
Author

Zgoda91 commented Jul 28, 2025

@ejona86 Could you please review this PR when you get a chance? Thanks!

@ejona86 ejona86 self-requested a review August 6, 2025 21:11
Copy link
Member

@ejona86 ejona86 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The shape of what I saw looked good. I didn't pay attention to any of the tests yet. I need to look through the provider plumbing more. But wanted to send the comments I have.

* limitations under the License.
*/

package io.grpc.alts;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why were these files added to alts? I'd have expected xds.

import java.nio.charset.StandardCharsets;
import org.junit.rules.TemporaryFolder;

public class JwtTokenFileTestUtils {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are only used by one test, and I don't expect many other tests to use this. We'd typically just have these as private methods in the test class. But if you do really want this in a separate file, that's fine, but just have it sit next to the test until it seems like it is going to be used.

If you are going to keep this as a separate file, you probably should remove the TemporaryFolder usages in the class. That is mixing responsibilities and reduces the reusability.

return jwtToken;
}

public static File createValidJwtToken(TemporaryFolder tempFolder, Long expTime)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/Long/long/. It doesn't look like null is valid.

String target, Object implSpecificConfig, boolean ignoreResourceDeletion,
String target,
Object implSpecificChannelCredConfig,
@Nullable Object implSpecificCallCredConfig,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of having separate Channel and Call creds explicitly here, can we use io.grpc.CompositeChannelCredentials instead to just continue using the implSpecificChannelCredConfig? I've not tried to follow the data flow yet.

* A wrapper class that supports {@link JwtTokenFileXdsCredentialsProvider} for
* Xds by implementing {@link XdsCredentialsProvider}.
*/
public class JwtTokenFileXdsCredentialsProvider extends XdsCredentialsProvider {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

final. Almost every (non-test) class should be final; we had lots of problems with users mocks doing impossible things, and final makes it harder for people to mess it up. Even places you think "it's impossible for a mocking framework to extend this class" like if the class isn't public... mocking frameworks can still do surprising things.

* See gRFC A97 (https://github.com/grpc/proposal/pull/492).
*/
public final class JwtTokenFileCallCredentials extends OAuth2Credentials {
private static final long serialVersionUID = 452556614608513984L;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI: You can just use the value 0 or 1, or your favorite number 42. The ugly computed number is necessary when you were previously relying on the JVM to calculate the version for you, and you want to remain compatible with the previously-computed value.

*/
public final class JwtTokenFileCallCredentials extends OAuth2Credentials {
private static final long serialVersionUID = 452556614608513984L;
private String path = null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

final

private String path = null;

private JwtTokenFileCallCredentials(String path) {
this.path = path;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

checkNotNull(path, "path")

Any time we save a value for later, we should be checking for null if it shouldn't be null. That means it is more likely the stack trace will tell us who provided the wrong value. The "path" string is an arbitrary semi-unique string, and useful just because line numbers can be unreliable (the number of times users don't know the version they are running or are incorrect...). We just repeat the variable name because it is unique (for the function), short, and requires zero thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants